%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Security Tasks
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Security Tasks}




%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Task B
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Task B}

The concerns of this task are of confidentiality and integrity:
\begin{itemize}
	\item No information stored on the system should be available to unauthorized users. SABMobile gets all data from the SAB system, so all data needs to be transmitted in secrecy.
	\item Only the application should be able to alter the data.
\end{itemize}

The pattern selected for this task is Encrypted Storage.

All data on the SABMobile application is encrypted with a PIN specific to the application. All cached data and stored customer credentials are encrypted with this PIN. All data transmission between the SABMobile application and the SAB system happens over a secure channel. This way, no sensitive information can be read or changed.

To ensure that only transactions between the customers and the beneficiaries are allowed, the SAB system checks each request and validates whether the beneficiary is listed.





%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Task C
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Task C}
The concerns of this task are of Confidentiality and Integrity. Only requests from trusted sources should reach the system.

The pattern selected for this task is Firewall.

Sensitive components of the system are not exposed to the Internet. All requests come in through the LoadBalancer. The LoadBalancer is extended with a Firewall which first checks the source of the request [figure \ref{fig:task_C}]. Only requests originating from the SABOnline website and the SAB Mobile application are forwarded to the respective facades.


\begin{figure}[!ht]
    \centering
        \includegraphics[width=1.0\textwidth]{images/fig_C}
    \caption{Top Level Overview component diagram after task C}
    \label{fig:task_C}
\end{figure}



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Task D
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Task D}
The challenge is to provide a single sign-on system for the SABOnline user. The customer can't provide their credentials for every action.

The attacker's goal that is relevant here is Spoofing. Once the credentials are broken it is of course possible to compromise the rest of the system.

The relevant attacks are:
\begin{itemize}
	\item Spoofing
	\begin{itemize}
		\item Password guessing attack
		\item Weak credential transit
		\item Weak credential-change management
		\item Server spoofing due to weak server-credential storage
		\item Weak client-credential storage
	\end{itemize}


	\item Denial of Service
	\begin{itemize}
		\item DoS
		\item Session killing
	\end{itemize}
\end{itemize}

To support single sign-on we provide a CustomerSession module that allows the customer to log into SAB Online once with his credentials over a secure channel [figure \ref{fig:task_D}]. If the credentials are incorrect the customer will be asked again for the correct credentials, and this for a maximum of 3 times a day. It authenticates the customer based on his credentials and a secure customer session token is generated and send back to the Customer Web Browser in a secure way. This secure token is used to further authenticate and authorize the customer during the session when he uses the different SABOnlineFacade components. All requests are sent over a secure channel so the token isn't compromised. The token is invalidated and removed from CustomerSession once the customer logs out.

For this solution to work well with the LoadBalancer, the load balancer needs to know about user sessions. This is because a session's token is only stored in one server and all requests need to go to that server. As a consequence the LoadBalancer practically only distributes sessions, over the servers, in stead of requests. This isn't a problem because sessions only consist of a few requests, with some time in between.

We also considered queuing all user actions at the client and requesting the user's credentials at the last moment. However, the example goes "checking his balance before performing a number of payments (transfers)." which would require the user to authenticate themselves two times because authentication is needed to check the balance. This could also overload the servers because all user action requests come in as one.

\begin{figure}[!ht]
    \centering
        \includegraphics[width=1.0\textwidth]{images/fig_D}
    \caption{Top Level Overview component diagram after task D}
    \label{fig:task_D}
\end{figure}






%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Task E
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Task E}
The concerns of this task are about accountability, Employees should not be able to perform actions and deny them later on.

The attacks that need to be prevented are:
\begin{itemize}
	\item Tampering: A bad employee wants to use his position to alter data in his own interest.
	\item Repudiation: A bad employee wants to perform actions in his own interest without being identified.
	\item Information disclosure: A bad employee wants to use his position to access data in his own interest.

\end{itemize}

The pattern selected for this task is Secure Logger.

After authentication, every action performed by the clerk with the ClerkFacade is audited by the SecureLogger. It logs the request to SecureLogStorage [figure \ref{fig:task_E}]. The log entry contains the ID of the clerk, the action he performed and the ID of the related customer. The SecureLogStorage can only be accessed with LogAction and ReadLog; the data can't be altered.

\begin{figure}[!ht]
    \centering
        \includegraphics[width=1.0\textwidth]{images/fig_E}
    \caption{Top Level Overview component diagram after task E}
    \label{fig:task_E}
\end{figure}




%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Task F
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Task F}
This task is about Elevation of Privilege and not about Spoofing because we have to focus on authenticated users trying to misbehave.

The attacker's goal here is to perform actions on accounts that are not theirs.

The current system only performs authentication, but no authorization after that. The weak interfaces are ConsultMobileAccount, IssueMobileTransfer, IssueTransfer and ManageBankAccounts.

The weaknesses are:
\begin{itemize}
	\item A request could ask for a transaction history of an account that does not belong to the customer.
	\item A request could ask for a transaction with a source account that does not belong to the customer.
	\item A mobile request could ask for a transaction with a destination account that is not in the customer's contact list.
\end{itemize}


The solution is to add functionality to CustomerAuthenticationEnforcer and MobileAuthenticationEnforcer so that they can also authorize requests. We replaced them with CustomerAuthenticationAuthorizationEnforcer and MobileAuthenticationAuthorizationEnforcer to reflect the change [figure \ref{fig:task_F}]. The components have access to the AccountManager to check whether the customer is allowed to use the bank accounts. The request is denied when it infringes on any of the weaknesses mentioned above.

The CheckUserCredentials interfaces, offered by the enforcer components, now also provide methods to check whether a customer is allowed to use a bank account for a specific action.

As a result, all customer requests coming through the SABMobileFacade and SABOnlineFacade to AccountManager, TransactionSchedulingModule and TransactionStoreManager are now authorized by the enforcer components.

In addition to authorization, we also make sure all credentials are sent over secure channels.


\begin{figure}[!ht]
    \centering
        \includegraphics[width=1.0\textwidth]{images/fig_F}
    \caption{Top Level Overview component diagram after task F}
    \label{fig:task_F}
\end{figure}




%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Task G
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Task G}
The security issue is that we need to send sensitive information over an untrusted public network. We solve the problem with authentication of the user (the customer's credentials) and the server (public certificates). Cryptography can be used to hide the data, and to protect the integrity of the data and the authentication sent over the network. Messages are assigned sequence numbers to ensure no requests (especially transfers) are dropped or repeated.


